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Microprocessor Verification 


• VIPER, the first commercially available, 
"verified” microprocessor, has never been 
formally verified. 


• The proof was not completed even though 
2 years were spent on the verification. 
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Microprocessor Verification 

(continued) 


Our research is aimed at making the verifi- 
cation of large microprocessors tractable. 

Our objective is to provide a framework in 
which a masters-level student can verify 
VIPER in 6 person-months. 



Determining Correctness 


In VIPER (and most other microprocessors), 
the correctness theorem was shown by proving 
that the electronic block model implies the 
macro— level specification. 


Macro Level 
Interpreter 


Electronic BlocF 
Model 
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The Problem 


(continued) 


Microprocessor verification is done through case analysis on the in- 
structions in the macro level. 


• The goal is to show that when the conditions for an instruction’s 
selection are right, the electronic block model implies that it operates 
correctly. 

• A lemma that the EBM correctly implements each instruction can be 
used to prove the top-level correctness result. 
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The Problem 

Unfortunately, the one— step method doesn’t 
scale well because 

• The number of cases gets large. 

• The description of the electronic block 
model is very large. 
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Hierarchical Decomposition 



• A microprocessor specification can be de- 
composed hierarchically. 


• The abstract levels are represented explic- 
itly. 
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Interpreters 


An abstract model of the different layers in the hierarchy provides a method 
ological approach to microprocessor verification. 


• The model drives the specification. 


• The model drives the verification. 
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Interpreters 

(top level) 
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Specifying an Interpreter 

(overview) 

We specify an interpreter by: 

• Choosing a n— tuple to represent the state, 
S. 

• Defining a set of functions denoting indi- 
vidual interpreter instructions, J. 

• Defining a next state function, N. 

• Defining a predicate denoting the behavior 
of the interpreter, I. 
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Verifying an Interpreter 

(overview) 


We verify an interpreter, I with respect to its 
implementation M by showing 

M =>1. 

To do this, we will show that every instruction 
in J can be correctly implemented by M: 


Vi € J. 

M =*> (Vf:time. 

C(t) =» a(t + n) = i(s(f))) 

where C represents the conditions for instruc- 
tion j’s selection. 


20 



AVM-1 


We have designed and are verifying a micro- 
computer with interrupts, supervisory modes 
and support for asynchronous memory. 

• The datapath is loosely based on the AMD 
2903 bit-sliced datapath. 

• The instruction format is very simple. 


• The control unit is microprogrammed. 
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AVM-1 's Instruction Set 

(subset) 



■Rlaraaafdatl^l 

Operation 


JMP 

jump on 16 conditions 


“CALL 

call subroutine 


rrm — ~ 

user interrupt ~~ ! 


LD 

load 

■»nnma 

ST 

store 

mam 

ADD 

add (3-operands) 

T«)>W 


subtract immediate (2-operands) 


In T Umbu ■ i i in ii ii^ —i 


• The architecture is load-store. 


• The instruction set is RISC-like. 


• There is a large register file. 


50 





Figure 5.2: The AVM-1 Datapath 












The Phase-Level Specification 


The n— tuple representing the state: 


S phase = ( mir,mpc,reg , 

alatch , blatch , mar, mbr , 
cZfc, mem , urom , ireg, zacfc) 
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The Phase-Level Specification 


A typical function specifying an instruction's 
behavior from J phase : 

b (jef phase_two rep (mir, mpc, reg, alatch, blatch, 

mbr, mar, elk, mem, urom, 
ireq, iack) = 

(mir, mpc, reg, 

EL (bt5_val (SrcA mir)) reg, 

EL (bt5_val (SrcB mir)) reg, 

mbr, mar, (T,F), mem, urom, ireq, lack mir) 
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The Electronic Block Model 


The electronic block model is not specified as 
an interpreter. 


• EBM is a structural specification. 

• The specification 

— is in terms of smaller blocks. 

— uses existential quantification to hide 
internal lines. 
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Objects 


There are several abstract classes of objects 
that we will use to define and verify an ab- 

f 

stract interpreter. 


: estate An object representing system 
state. 

: *key The identifying tokens for instruc- 
tions. 

: time A stream of natural numbers. 

We will prime class names to indicate that the 
objects are from the implementing level. 
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Operations 


Operation 

Type 

instJist 

: ( *key x ( estate — ► *state))list 

key 

: *key — ► num 

select 

: * state — ► *key 

cycles 

: *fcey — * num 

substate 

: estate' — > *state 

Impl 

: ( time — ► *state r ) — ► frooZ 

clock 

: estate' — » *key' 

begin 

: *key' 
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Interpreter Theory 
(obligations) 


The instruction correctness lemma is impor- 
tant in the generic interpreter verification. 

Here is the generic version of that lemma for 
a single instruction: 

f ~def INST.CORRECT s' inst = 

(Impl s') =>• 

Vt' : time'. 

let s = (Af. substate(s' t')) in 
let c = (cycles(select(s t '))) in 
(select(s t') = (FST inst)) a 
( clock(s' t') = begin) =>- 
((SND inst) (s t') = (s(t' + c))) A 
(clock(s'(f' -|- c)) = begin) 
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Interpreter Theory 

(obligations) 


Using the predicate INST_CORRECT, we can 
define the theory obligations: 

1. The instruction correctness lemma: 

EVERY (INST_CORRECT s') instJist 

2. Every key selects an instruction: 

Vfc : *key. (key k) < (LENGTH instJist) 

3. The instruction list is ordered correctly: 

Vfc : *key. k = (FST (EL (key fc) instJist)) 
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Generic Interpreters 

Instantiation 



Generic 
Interpreter 



/"“Macro LeveK 
^Defmitions^ 


Macro Level 
Interpreter 



Generic 
Interpreter 




Micro Level 
Definitions 


Micro Level 
Interpreter 



Generic 
Interpreter 



/''Phase LeveTN 
V^De^itions^/ 


Phase Level 
Interpreter 


Electronic Block 
Model 
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Interpreter Theory 

(temporal abstraction) 


We need to show a relationship between the 
state stream at the implementation level and 
the state stream at the top level. 
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The function / is a temporal abstraction func- 
tion for streams. 


! 
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Interpreter Theory 

(definition) 


An interpreter’s behavior is specified as a pred- 
icate over a state stream. 


\- def INTERP s = 

Vi : time. 

let n — (key(select(s f))) in 

s(f + 1) = (SND (EL n inst_list))(s t) 
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Interpreter Theory 

(correctness result) 


Our goal is to verify an interpreter, I with 
respect to its implementation M by showing 

M =*> I. 

Here is the abstract result: 

p Impl s' A (clocks' 0) = begin) =4- 

INTERP (so/) 

where 

s = (A t : time. substate(s' <)) and 
/ = (time.abs (cycles oselect)s) 
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Instantiating a Theory 

Instantiating the abstract interpreter theory 
requires: 

• Defining the abstract constants. 

• Proving the theory obligations. 

• Running a tool in the formal theorem prover. 


71 


Definitions 


We wish to instantiate the abstract interpreter 
theory for the phase-level. The electronic 
block model will be the implementing level. 


Operation 

Instantiation 

instJist 

a list of instructions 

key 

bt2_val 

select 

GetPhaseClock 

cycles 

PhaseLevelCycles 

substate 

PhaseSubstate 

Impl 

EBM 

clock 

GetEBMCIock 

begin 

EBM .Start 
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An Example 


After proving the theory obligations, we can perform 
the instantiation. 

let theorem_list = 

instant iate__abstract_theorems 
*gen_I ; 

[Phas e _ I _EVERY_LEMMA ; 

Phase_I_LENGTH_LEMMA ; 

Phase _ I _KE Y_LEMMA] 

[ 

" ( [(F,F) ,phase_one ; 

(F,T) ,phase_two 
(T,F) ,phase_three 
(T,T) ,phase_four] , 
bt2_val, GetPhaseClock, 

PhaseLevelCycles , PhaseSubstate , 

EBM, GetEBMClock, EBM_Start)"; 

"(A trtime. (mir t, mpc t, reg_list t, 

alatch t, blatch t, 
mbr_reg t, mar_reg t, 
elk t, mem t, urom))" 

] 

’ PHASE , ; ; 


Up - 


73 



The Electronic Block Model 


h EBM rep (A t. (mir t, mpc t, reg t, alatch t, blatch t, 

mbr t, mar t, elk t, mem t, urom, 
ireq t, iack t)) = 

3 opc ie_s sm_s iack_s 

amux_s alu_s sh_s mbr_s mar_s rd_s wr_s 

cselect bselect aselect 

neg_f zero_f (f loat : time - >bool) . 

DATAPATH rep amux_s alu_s sh_s mbr_s mar_s rd_s wr_s 
cselect bselect aselect neg_f zero_f float 
float ireq iack_s iack opc ie_s sm_s 
elk mem reg alatch blatch mar_reg 
mbr_reg reset_e ireq_e A 

CONTROL.UNIT rep mpc mir elk amux_s alu_s sh^s mbr_s 

m ax_s rd_s wr_s cselect bselect aselect &eg_f 
zero_f ireq iack_s opc ie_s sm_s urom 
reset_e ireq.e 


Fully expanded, the electronic block model 
specification fills about six pages. 
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Future Work 


• New architectural features. 


• Composing verified blocks. 


• Verifying operating systems. 


• Gate— level verification. 


• Byte-code interpreter verification. 


• Other classes of computer systems. 



An Example 

(continued) 

After some minor manipulation, the final result be 
comes: 

h EBM 

(At. 

(mir t ,mpc t,reg_list t,alatch t,blatch t, 
mbr.reg t,mar_reg t, elk t,mem t,urom)) ==> 
Phase_I 

(mir t,mpc t,reg_list t,alatch t,blatch t, 
mbr_reg t,mar_reg t, elk t,mem t,urom)) 
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Conclusions 


The generic proof 

• Cleared away all the irrelevant detail. 

• Formalized the notion of interpreter proofs 
which has been used in several micropro- 
cessor verifications. 


• Provided a structure for future micropro- 
cessor verifications. 
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